home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000824-20010305 / 000301_news@columbia.edu _Fri Feb 16 09:45:38 2001.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by uhaligani.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA19431
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Fri, 16 Feb 2001 09:45:37 -0500 (EST)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id JAA07549
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 16 Feb 2001 09:45:36 -0500 (EST)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id JAA03007
  10.     for kermit.misc@watsun.cc.columbia.edu; Fri, 16 Feb 2001 09:40:42 -0500 (EST)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: fdc@columbia.edu (Frank da Cruz)
  13. Subject: Re: interfacing to FANUC CNC controller
  14. Date: 16 Feb 2001 14:40:42 GMT
  15. Organization: Columbia University
  16. Message-ID: <96je5a$2ts$1@newsmaster.cc.columbia.edu>
  17. To: kermit.misc@columbia.edu
  18.  
  19. In article <oFaj6.275447$w35.45475640@news1.rdc1.nj.home.com>,
  20. dls2 <dlshearer@home.com> wrote:
  21. : I'm having some strange communications problems,
  22. : in having Kermit communicate with a FANUC CNC
  23. : controller.  I should be able to upload and download,
  24. : fine, with no problems, but that is just not happening.
  25. : 
  26. : All of the hardware being interfaced is known to be
  27. : good, so this is very unlikely to be causing problems.
  28. : 
  29. : The connection between the FANUC CNC controller
  30. : and the computer running K95 is a direct connection,
  31. : being made through serial cabling, using an unknown
  32. : pinout.  The cable being used is known to be good,
  33. : despite its unknown pinout, due to the two facts that:
  34. : 
  35. :     1.) The serial cable does work, as intended, when
  36. :     used to connect the FANUC CNC controller to a
  37. :     different computer, making use of ProComm Plus,
  38. :     instead of Kermit.  (NB: serial ports working, here.)
  39. : 
  40. When trying to isolate faults, it is usually best to change
  41. one thing at a time, not multiple things.
  42.  
  43. :     2.) Hardware flow control is not being utilized,
  44. :     in deference to software flow control, if any.
  45. : 
  46. : The serial port on the computer running K95 is known
  47. : to be good, for similar reasons, having been used, in
  48. : other capacities, elsewhere.
  49. : 
  50. Yes, but has it been used by K95?  As you know, any serial
  51. port above COM2 on a PC is problematic due to interrupt
  52. conflicts.  In late-model PCs, COM3 and above, if present,
  53. might not be real serial ports.  In that case, it might
  54. be necessary to open them under their Windows names, not
  55. their PC device names.
  56.  
  57. : As far as the settings used for communications,
  58. : the port (COM5), port speed (9600 baud), parity
  59. : (even), and stop-bits (2), have been set, as known
  60. : to be needed.
  61. :
  62. : Duplex has been tried in both half
  63. : and full, flow control has been tried in none, rts/cts,
  64. : and xon/xoff, handshaking has been tried in none
  65. : and xon, all to no affect, and no avail.
  66. : 
  67. : The settings, from the ProComm Plus arrangement,
  68. : indicate that half duplex and xon/xoff flow control are
  69. : required.  Settings other than 9600 baud, 7e2, full-
  70. : duplex, and xon/xoff flow control, like handshaking,
  71. : do not appear to be specified one way, or another,
  72. : and, so, have, really, only been guessed at.
  73. : 
  74. : Data is supposed to be transfered as readable, 7-bit,
  75. : ASCII, text, from the FANUC CNC controller, through
  76. : RS-232, to the computer running K95, and back, again,
  77. : for purposes of backing up, and restoring, the data.
  78. : 
  79. Without protocol, right?
  80.  
  81. : Downloads, using K95, have been done using session
  82. : logs.  The captured data is identical to that acquired by
  83. : the ProComm Plus arrangement, with two important
  84. : differences.  The first difference is in the data header,
  85. : where instead of the expected percent sign (%), there
  86. : is a DC (Device Control) character (up/down arrow)
  87. : placed before the percent sign (%), in the closed session
  88. : logs.
  89. :
  90. K95 would not record this character if it did not come in.
  91. But DC1 is Ctrl-Q or XON.  If Kermit sees this as a data
  92. character, this would indicate that you did not SET FLOW
  93. XON/XOFF.
  94.  
  95. : The second difference is in the data footer, where
  96. : instead of the expected percent sign (%), there is a DC
  97. : (Device Control) character (paragraph symbol) placed
  98. : after the percent sign (%), in the closed session logs.
  99. :
  100. DC-what?  The Device Control characters are DC1, DC2,
  101. DC3, and DC4, codes 0x11-0x14.
  102.  
  103. : A
  104. : double carriage return (single note symbol) may, or may
  105. : not, appear in the body of the text data downloaded by
  106. : either ProComm Plus or K95, resultant from settings to
  107. : the FANUC CNC controller, regarding communications.
  108. : 
  109. : Why are DC (Device Control) characters appearing in
  110. : the K95 session logs, and not in the ProComm Plus
  111. : downloads?  Handshaking?
  112. : 
  113. You probably set Xon/Xoff flow control in PCplus but not
  114. K95.
  115.  
  116. : Would the appearance of these DC (Device Control)
  117. : characters in the K95 session logs I make account for
  118. : why I cannot upload the same files back to the FANUC
  119. : CNC controller, using "xmit <filename>", even after I
  120. : strip these DC (Device Control) characters from the
  121. : session logs?
  122. : 
  123. How are you attempting to upload these files?
  124.  
  125. : In some upload attempts, with whatever setting changes
  126. : were being tried, had an up/down arrow or, sometimes, a
  127. : double exclaimation mark, DC (Device Control) character
  128. : appear before a percent sign (from the data?) just prior to
  129. : having the transfer time out on the K95 end of transfer.
  130. : 
  131. First of all, let's straighten out the flow-control business.
  132. It seems you believe that K95 has Xon/Xoff flow control in
  133. effect when it does not.  Maybe that's the whole problem.
  134.  
  135. : Should I have transmit linefeed set to on?  This setting
  136. : needed to be on in order for the FANUC CNC controller
  137. : to recognize that data was even being sent to it, but
  138. : since all attempts to send data timed out, and nothing
  139. : was ever successfully transfered, I am unsure of if it is
  140. : really necessary.  (NB: to change LSK (Label SKip) to
  141. : an Input mode, on the FANUC CNC controller.)
  142. : 
  143. Aside from flow control, the real questions are:
  144.  
  145.  . What are you supposed to be sending to the controller?
  146.  . Exactly what format is it supposed to be in?
  147.  . When are you supposed to send it?  Are you supposed to
  148.    wait for a prompt, or what?
  149.  
  150. Is the connection full or half duplex?  If you do this
  151. by hand, does the controller echo what you type?  What if
  152. you type something too soon?  Does the controller support
  153. typeahead?  etc etc.
  154.  
  155. - Frank